matic problem which will strongly influence coming pro- 
gramming languages. Not only will conversational fea- 
tures be essential, there may even be a trend back from all 
too sophisticated language systems to the simple pointing 
with a light-pen. Pointing has always been one of the 
safest ways to convey information. 

We come back to Wittgenstein and his principle of 
speaking clearly or not speaking at all. Since we know that 
it is the computer which we can make speak arbitrarily 
clearly, we possibly should try to let the computer speak 
more and more and to restrict the human user in the 
practical situation to point at YES or NO, or some more 
equally simple choices, while the computer talks. This may 
sound like science fiction today, but it could really be true 
that one day this will become the central application of 
pragmatics around the computer. 
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Introduction 


An increasing percentage of computation activity will 
be carried out by multiprogrammed computer systems. 
Such systems are characterized by the application of com- 
putation resources (processing capacity, main memory, 
file storage, peripheral equipment) to many separate but 
concurrently operating computations. 

We can cite three quite different examples of multipro- 
grammed computer systems to illustrate their diversity of 
application. The American Airlines SABRE passenger 
record system couples ticketing agents at dispersed offices 
to a central data file [1]. The computer support systems of 
NASA provide real time control and monitoring of manned 
space flights [2]. The Project MAC time-sharing system 
permits research workers closer interaction with the powers 
of automatic computation [3]. Although these are all on- 
line systems, multiprogramming techniques have also been 
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used successfully in systems that perform computations on 
an offline, job-shop basis. 

We review some of the distinctive properties of a multi- 
programmed computer system (MCS), and then introduce 
some concepts and terminology that have proven useful in 
studying the properties of multiprogrammed computa- 
tions. As we proceed, we define a number of meta-in- 
structions that embody powers mostly absent from con- 
temporary programming languages, but essential to the 
implementation of computation processes in an MCS. 
These powers relate to (1) parallel processing, (2) naming 
objects of computation, and (8) protection of computing 
entities from unauthorized access. The character of these 
meta-instructions is such that they might form part of a 
language intermediate in sophistication between an as- 
sembly language and an advanced algebraic language for 
an MCS. In fact, the semantics of these meta-instructions 
could be incorporated in the definition of an intermediate 
language that might be employed at some stage in the 
translation of a more advanced language. 

We do not claim completeness for the set of meta- 
instructions to be described. Additional operations will 
prove necessary in practice for a specific MCS. In particu- 
lar, no means is discussed whereby an object computation 
may advise the supervisor of special scheduling or alloca- 
tion requirements, Also, conventions for dynamic control 
of segment length have been omitted. 


Properties of Multiprogrammed Computer Systems 


Five properties of multiprogrammed computer systems 
are important to the present discussion. 

(1) Computation processes are in concurrent operation 
for more than one user. A multiprogrammed computer 
System is generally the creation of many individuals work- 
ing in part toward a common objective and in part for 
private goals. A successful MCS must include mechanisms 
for preventing undesired interference among computations. 

(2) Many computations share pools of resources in a 
flexible way. In consequence, the individual planner of a 
computation need not be concerned about efficiently using 
a certain fixed amount of memory and processing capacity 
which would otherwise go to waste. Resources not used by 
one computation are available to other concurrent compu- 
tations. 

(3) Individual computations vary widely in their de- 
mands for computing resources in the course of time. 

An MCS must have mechanisms (explicit or implicit) 
through which a computation may request and release re- 
sources according to need. Where many computations are 
active, which are not closely coupled in their demands for 
resources, the peak demands of some computations will 
coincide with the slack demands of others. As the number 
of computations in the system is increased, the instan- 
taneous total demand for resources will hover closer to 
the sum of the individual average demands. Therefore, 
the amount of physical resources required in such an MCS 
is governed by the average demand over all computations 
rather than by the sum of their peak demands. 
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(4) Reference to common information by separate com- 
putations is a frequent occurrence. 

In an MCS it is advantageous to allow information to 
be common among computations proceeding for different 
users to avoid needless duplication of procedures and data. 
Also, communication among separately planned com- 
putations is essential to many MCS objectives. Further- 
more, the sharing of a peripheral device by several com- 
putations is sometimes required. 

(5) An MCS must evolve to meet changing require- 
ments. 

An MCS does not exist in a static environment. Chang- 
ing objectives, increased demand for use, added functions, 
improved algorithms and new technologies all call for 
flexible evolution of the system, both as a configuration of 
equipment and as a collection of programs. 

To meet the requirements of flexibility of capacity and 
of reliability, the most natural form of an MCS is as a 
modular multiprocessor system arranged so that proces- 
sors, memory modules and file storage units may be added, 
removed or replaced in accordance with changing require- 
ments [4]. 


Concepts and Terminology 


Segments. The smallest unit of stored information that 
is of interest in the present discussion is called a word. An 
ordered set of words grouped together for purposes of 
naming is called a segment. A segment is created at some 
point in time and has a definite length (which may vary 
with time) at any instant of its existence. 

Any reference by a computation to data or procedure 
information is specified by a word name, w = [i, a], con- 
sisting of the index number 7 of the segment containing the 
desired word and a word address a giving the position of the 
word within the segment. The index number may be 
thought of as an abbreviation for the name of the segment. 
The correspondence between an index number and a name 
is established by meta-instructions which will be defined 
subsequently. 

In the programming examples (which are written in a 
pseudo-ALgou format) variable identifiers, array identifiers 
and labels will stand for word names. Word names are 
written here as [z, a] only when the index number must be 
explicitly mentioned. 

The concept of segment has influenced the design of a 
commercial computer (the Burroughs B5500), an experi- 
mental machine [5] and one military system (the Bur- 
roughs D825). The use of segments in software systems is 
discussed by Greenfield [6], Holt [7] and others. The design 
of addressing mechanisms for MCS8’s is discussed by 
Dennis [8]. A fuller implementation of these concepts in a 
machine organization has been discussed by Glaser, 
Couleur and Oliver [9], and interesting work in a similar 
direction is in progress at the MIT Lincoln Laboratory 
{10], IBM [11] and is continuing at Burroughs [12]. 

Protection. In an MCS, a computation must be denied 
access to memory words and other objects of computation 
unless access is authorized. In particular, it seems natural 


Volume 9 / Number 3 / March, 1966 


to implement memory protection on a segment basis. Thus, 
we think of a computation as proceeding within some 
sphere of protection [13] specified by a list of capabilities or 
C-list for short. Each capability in a C-list locates by 
means of a pointer! some computing object, and indicates 
the actions that the computation may perform with re- 
spect to that object. Among these capabilities there are 
usually several segment capabilities, which designate seg- 
ments that may be referenced by the computation and 
also give, by means of access indicators, an indication of 
the kind of reference permitted: 


x executable as procedure including internal read references 
for constants. 

R readable as data but not executable. 

XR executable as procedure and readable as data. 


RW readable and writeable as data. 
XRW executable as procedure and readable and writeable as 
data. 

Other types of capability are also permitted in the C-list 
of a computation, and are introduced in the discussion as 
appropriate. Every capability contains an ownership 
indicator (O for owned, N for not owned). Computations 
have broad powers with respect to owned computing ob- 
jects, through mechanisms to be described. In the case of 
an owned segment, for example, a computation may 
delete the segment, and grant or deny other computations 
access to the segment. 

During the execution of a computation, capabilities 
will frequently be added to and deleted from the C-list 
defining its sphere of protection through the use of meta- 
instructions to be described in later sections. The linear 
subscript of a capability within a C-list is called its index- 
number. It is through the use of the index number that the 
capability is exercised by processes. For example, a seg- 
ment is referenced by giving the index number of the seg- 
ment in a word name. We assume that the allocation of 
these index numbers is carried out by the system (i.e., the 
supervisor program) during the execution of an object 
computation. 

Processes. We consider that the system hardware com- 
prises one or more processors, which we can identify as 
being distinct from the main memory, the file storage de- 
vices and the input/output devices. Each processor is 
capable of executing algorithms that are specified by se- 
quences of instructions. A process is a locus of control 
within an instruction sequence. That is, a process is that 
abstract entity which moves through the instructions of a 
procedure as the procedure is executed by a processor. 

In a physical computer system a process is represented 
by the information that must be loaded into a processor in 


1 The term ‘pointer’ is used here because of its familiarity to 
most workers. The permanent representation of a pointer should 
not be a hardware address in the machine (main or auxilary 
storage), as it is essential that the entire naming structure be 
independent of physical device addresses if reallocation of storage 
media is to be feasible. The authors suggest the association of a 
unique code (called an effective name in [13]) with each computing 
entity (segment, directory, etc.), which is assigned at the time the 
entity is created. 
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order to continue execution of the successive instructions 
encountered by the process. We call this set of information 
the state word of the process, and note that it must not only 
contain the accumulator words, index words and the word 
name of the next instruction to be executed, but must also 
indicate the C-list applicable to the computation to which 
the process belongs. 

A process is said to be running if its state word is con- 
tained in a processor which is running. A process is called 
ready if it could be placed in execution by a processor if one 
were free. Running and ready processes are said to be 
active. A process that is not active is suspended and is 
awaiting activation by an external event, such as the com- 
pletion of an 7/o function. 

Computations. Loosely speaking, a computation may 
be thought of as a set of processes that are working to- 
gether harmoniously on the same problem or job. More 
precisely, we define a computation to be a set of processes 
having a common C-list such that all processes using that 
same C-list are members of the same computation. 

Notice that two processes having separate C-lists are 
always members of separate computations, even though 
these C-lists might describe the same set of capabilities. 
Notice also that there exist one-to-one correspondences 
among computations, spheres of protection and C-lists; 
each computation operates within the restrictions of a 
unique sphere of protection that is specified by a unique 
C-list. The relationship among these entities is shown 
schematically in Figure 1. 
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Principals. The ordinary notion of a user of an MCS is 
of an individual who requests computing service from an 
MCS, or who interacts with a time-shared MCS from a 
console. We generalize this notion by defining the term 
principal to mean an individual or group of individuals to 
whom charges are made for the expenditure of system 
resources. In particular a principal is charged for resources 
consumed by computations running on his behalf. A prin- 
cipal is also charged for retention in the system of a set of 
computing entities called retained objects, which may be 
program and data segments, for example. The structure 
and identification of these retained objects is discussed in 
a later paragraph. 

We can clarify our notion of a principal by giving some 
examples. Each individual user of the MAC time-sharing 
system acts as a principal, since he js able to utilize system 
resources to achieve any personal goal—restricted only by 
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an. accounting of his expenditure of basic resources. He 
may create, modify and delete segments of procedures and 
data solely according to his personal objectives. In the 
MAC system we also find principals consisting of groups 
of individuals. Such a group principal might be responsible 
for the maintenance of a system of procedures that solves a 
certain class of mathematical problems (e.g., matrix opera- 
tions or statistical analysis). Another group principal might 
have cognizance over a programming language system 
including editing routines, compiling routines and de- 
bugging aids. Still a third principal might oversee the 
common procedures of an extensive design project involv- 
ing the cooperative effort of many people. 

In the case of an airline information processing system, 
the agents do not participate as principals but simply com- 
municate with a set of procedures that enable them to per- 
form well defined interrogations of and operations on a 
centrally stored data base. In such a system, a principal 
might consist of a team of system planners and program- 
mers responsible for the success of a single aspect of the 
system’s mission. Examples of such separate aspects are 
passenger records, aircraft scheduling and accounting. 

In the case of computer support for a manned space 
flight, separate principals could be responsible for different 
aspects of the mission—guidance during propulsion, 
tracking while in orbit, orbital computation, medical 
data processing, etc. 


The Supervisor 


The term supervisor is used here to denote the combina- 
tion of hardware and software elements that together im- 
plement a core of basic computer system functions around 
which all computations performed by the system are con- 
structed. For present purposes we suppose that the core of 
functions includes mechanisms for (1) allocation and 
scheduling of computing resources, (2) accounting for and 
controlling the use of computing resources, and (3) im- 
plementing the meta-instructions. 

We do not inquire in the present paper as to the internal 
workings of the supervisor required to perform the above 
functions. Instead it is our aim to point out the essential 
features of the interface between the supervisor and user 
processes which operate in lower spheres of protection. 
However, it is helpful to think in more concrete terms 
about how the supervisor accomplishes some of its func- 
tions. 

The Process List. Specifically, let the process list be a 
data structure within the supervisor, with an entry for 
each process existing in the system. Entries are created in 
and removed from this list by various meta-instructions 
and by other mechanisms that will be described. Each 
entry can hold the state word of its corresponding process, 
as well as accounting and scheduling information. 

As mentioned before, each process is either running, 
ready or suspended. 

Allocation and Scheduling. At any time segments of 
information will be distributed among a hierarchy of 
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storage devices (core, drum, disk and tape, for example) 
with that information most relevant to the on-going 
computation processes located in the more accessible 
media. With each computation there is associated a set of 
information to which it requires a high density (in time) 
of effective reference. The membership of this working set 
of information varies dynamically during the course of the 
computation. The supervisor’s problem is to decide how 
information (segments) should be distributed in the 
storage hierarchy and how the queue of active processes 
should be disciplined to make most effective use of system 
resources in accomplishing the MCS mission. 

Accounting and Control. We suppose the charges for 
the expenditure of computation resources associated with 
the execution of a process are assigned to the principal that 
was responsible for the creation of the process. We also 
assume that each principal is given an allotment of 
resources, and that appropriate action is taken by the 
supervisor if this allotment is exceeded. 


Parallel Programming 


Basic Primitive Operations. The basic primitive opera- 
tion of parallel programming is implemented by the meta- 
instruction 


fork w; 


as suggested by Conway [14] where w is a word name. A 
fork meta-instruction initiates a new process at the 
instruction labeled w. The newly created branch process is 
part of the same computation as its creator or main 
process; that is, it is associated with the same C-list. A 
process that has completed a sequence of procedure steps 
is terminated by the meta-instruction 


quit 


after which the process no longer exists and its state word 
is discarded from the process list. A set of primitives for 
parallel programming must include a mechanism whereby 
one process may be continued just when all of a certain 
set of processes have completed. All that is required is a 
procedure step that will decrement a count and test for 
zero. We use the instruction 
join t, w; 

which is essentially Conway’s join instruction. Here ¢ is the 
word name of the count to be decremented and w is the 
word name of an instruction word to be executed if the 
count becomes zero as indicated in Figure 2. It is essential 
that the three references to the count ¢ not be separated in 
time by references to ¢ from other processes. This require- 
ment is indicated by the dashed box in the Figure 2 and is 
readily achieved in practice by combining the two actions 
into one machine instruction that is completed with a 
single reference to the count word. 

In describing algorithms involving parallel processes, it is 
convenient to declare certain quantities as private to a 
process. For this purpose the declaration 


private z; 
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Fig. 2. The join procedure step 


means that the quantity named z is to exist only so long as 
the process executing the declaration exists; that is, 
private data is lost when a process quits. At a fork the 
values of any quantities declared private to the main 
process are assigned as values of corresponding quantities 
of the branch process. In practice, the state word of a 
process is the natural representation of private data. If 
there is more data declared private than can be represented 
in the state word, the system must create a segment for 
private data which is copied at each fork and lost upon 
reaching a quit. 

Lockout. A provision whereby two processes may 
negotiate access to common data is a necessary feature of 
an MCS. Suppose a certain data object (which might be a 
word, an array, a list structure, a portion or all of a seg- 
ment) may be updated asynchronously by several proces- 
ses, which are perhaps members of different computations. 
Updating a data structure frequently requires a sequence 
of operations such that intermediate states of the data are 
inconsistent and would lead to erroneous computation if 
interpreted by another process. 

The lockout feature proposed here presumes that all 
computations requiring access to the data object are well 
behaved. If it is desired to protect the data object from 
destructive manipulation by an untrustworthy computa- 
tion, routines with protected entry points as described 
later in this paper must be employed. 

We associate with the data object a one-bit lock in- 
dicator that is accessible to all processes requiring use of 
the data object. Two meta-instructions are introduced 
that operate on the lock indicator w. 


lock w; 


The effect of the lock meta-instruction is given in Figure 
3a. The lock bit is set to one just when the data object has 
been found unlocked by all other processes. Again, as 
indicated by the dashed box, the two references to w must 
not be separated by references to w from other processes. 
The meta-instruction 


unlock w; 


resets the lock indicator to zero as in Figure 3b. 


Volume 9 / Number 3 / March 1966 


b) 


> Ww: = 0 i> 


Fie. 3. Lock and unlock meta-instructions 


The use of these meta-instructions would typically be: 
lock w; 
2 update sequence for data object 
associated with lock indicator w. 


unlock w; 


In practice the execution time of a typical update 
sequence is quite small and the chance that a process will 
hang up on a lock instruction will be very low. However, a 
process may be removed from execution if a processor is 
preempted by a higher priority computation. Thus, a data 
object could remain locked for a substantial time if such 
preemption occurred between a lock/unlock pair. Then 
hangup of other processes interrogating that lock indicator 
could be highly probable. A solution to this problem is to 
inhibit interruption of a process between execution of a 
lock and execution of the following unlock. Of course, 
this requires that a time limit be set on the separation of 
lock/unlock pairs. 

An example. An elementary example of parallel 
programming that illustrates the use of these meta- 
instructions is the following program that evaluates that 
dot product of two vectors A and B. 


begin real array A{l:n], B[l:n]; 
Boolean w; real S; integer ¢; 
private integer 7; 


t:= 3 
for i := 1 step 1 until n do 
fork e; 

quit; 

e: begin private real X; 

substance: X := Af{t] xX Biz); 
lock w; 
S:=S84+X; 
unlock w; 
join t, 7; 
quit; 

end; 
r: 
end; 
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Obviously, this computation is too trivial for parallel 
programming to be of practical interest. If the algorithm 
expressed by the statement labeled substance, instead of 
being a simple multiplication, involved the operation of a 
large, complex system of procedures (e.g., the compilation 
of a segment of procedure), the notation of parallel process- 
ing as used above would allow several instances of that 
algorithm to be in simultaneous execution, thus more 
effectively utilizing the presence of its procedure informa- 
tion in main memory. 

Input/Oulput. A basic power of computations in an 
MCS is the ability to communicate with peripheral (input/ 
output) devices. Two classes of communication have 
evolved in terms of implementation in present day com- 
puter systems. In the simpler class a process requests the 
transmission of a unit of information (word or fraction of a 
word) to or from a peripheral device and waits in suspended 
status until the information is transmitted before con- 
tinuing. (A processor, as contrasted with the process, may 
be executing other processes during the wait interval, 
however.) This form of implementation is appropriate for 
low data-rate situations, and also where a close inter- 
action between the computation and the peripheral 
devices is required (e.g., quick response to brief inquiries 
from a remote console). 

In the second form of input/output operation, a se- 
quence of interactions between memory (i.e., a segment) 
and the peripheral device occurs in response to an initia- 
tion signal from a process. The process remains suspended 
until all interactions between memory and the peripheral 
device have been completed. 

In either case a principal characteristic of the input/ 
output operation is the elapse of time between initiation 
and completion. This input/output wait is generally long 
compared with the instruction execution time of a typical 
central processing unit. For present purposes we do not 
distinguish further between these two forms of input/ 
output operations, and call both by the term 7/o function. 

Since peripheral devices are part of the physical re- 
sources of a computer system, the use of i/o functions must 
be restricted to computations authorized to do so. It is 
natural to consider an i/o function as representing another 
class of capability that may be entered in the C-list that 
defines a sphere of protection. This capability is then 
exercised by the meta-instruction 


execute i/o function 7; 


where 7 is the index number of an i/o function capability 
in the C-list of the computation. Performance of this 
procedure step by a process causes initiation of the i/o 
function represented by the 7th entry of the C-list. The 
process then becomes suspended and remains so until the 
i/o function has completed. It then becomes active again 
to perform subsequent procedure steps. 

Particular stress has recently been placed on ability to 
specify computations that may compute in parallel with 
input/output operations. Within the scheme presented 
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here, this goal is easily achieved through the execution of 
fork meta-instructions prior to the execution of i/o func- 
tions. 

Motivation for Parallelism. The motivation for en- 
couraging the use of parallelism in a computation is not so 
much to make a particular computation run more ef- 
ficiently as it is to relax constraints on the order in which 
parts of a computation are carried out. A multiprogram 
scheduling algorithm should then be able to take advan- 
tage of this extra freedom to allocate system resources 
with greater efficiency. 

Moreover, the notation of parallel programming is a 
natural way of expressing certain frequently occurring 
operations of computations running in an MCS. Suppose, 
for example, we wish to program a computation to receive 
messages from any of a number of user consoles, where 
the messages are to arrive in some unknown and arbitrary 
order, and it is not known whether some consoles will ever 
send messages. Let listen(z, 7) be an integer procedure’ 
that waits for a message to be received from console 7 and 
writes the message in the segment with index number j. 
The value of listen is set to the number of symbols in the 
message. Let analyze(i, 7, 2) be a procedure which scans 
a message of n symbols received from console 7 and written 
in segment j, and takes whatever action is necessary in 
response to the content of the message. Then the message- 
receiving computation described above may be program- 
med as follows. 
begin private integer 7; 

for 7 := 1 step 1 until m do 

fork ¢; 
quit; 
e: begin integer j, 7; 
j := create segment RW; 
n := listen (i, 7); 
analyze (i, j, n); 
quit; 

end; 
end; 

The create segment meta-instruction introduces a 
segment capability into the C-list of a computation and is 
discussed in a following section. 


Inferior Spheres of Protection 


It is useful to think of a computation’s sphere of protec- 
tion as having been established by another computation, 
that is, by the action of a process operating within another 
sphere of protection. A major reason for taking this view 
concerns the debugging of programs in some programming 
language system (PLS). However, other uses of this 
concept are also possible. 

In connection with program testing (debugging), 
suppose that the processes of a PLS are carried out, as for 
any object computation, within some sphere of protection 
A. These processes must have access to all of the user’s 
computing objects pertinent to the program under test, 
as well as to the procedure segments of the PLS. Since the 
program under test is likely to be faulty, it is desirable to 
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protect both the user’s permanent objects, and any 
objects created by the PLS on his behalf from uninten- 
tional use or destruction by the procedure being debugged. 
To allow the processes under test to be operated within a 
sphere of protection distinct from the one effective for the 
PLS, we define several meta-instructions. 


7 i= create sphere w; Append an owned inferior sphere capa- 


bility to the C-list with index number 
4. The word name w is the return point 
for exceptional conditions, as ex- 
plained later. 


The process executing this meta-instruction operates in 
a sphere we call the superior of the created sphere. Once 
in possession of an inferior sphere capability (Figure 4), a 
process may grant some of its capabilities to the inferior 
sphere by the following meta-instruction. 
d | 
xX 


7:= grant e i J, ks; 
Oj; |) XR {”’° 

RW 

XRW 


Grant capability j to inferior sphere & with index number 7. 
Here j and & are index numbers in the current C-list, and 
zis an index number in the inferior C-list. 


The granted capability is entered in the C-list of inferior 
sphere k and may be a segment capability, i/o function 
capability, entry capability or directory capability. Entry 
and directory capabilities are discussed in later paragraphs. 
The braces mean that one of the strings within them must 
be selected to form part of the meta-instruction. Here \ 
stands for the null string. The string O indicates that the 
inferior sphere is to have ownership powers with respect 
to the granted capability. The other strings can be used 
only if j is the index number of a segment capability. In 
this case the capability is passed down with restricted 
access authority. For example, 


@:= grant X j,k; 


grants authority to execute the segment but not to read 
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it, write it or exercise ownership of it. The grant meta- 
instruction cannot be used to pass a capability that is not 
implied by a capability present in the higher sphere. 


start 7, w; Initiate a process at instruction word name w 


within inferior sphere 7. 


The new process commences with no private data, that is, 
a zero state word except for the instruction word name w. 

Exceptional Conditions. Next we ask what should 
happen if a process operating in an inferior sphere en- 
counters an exceptional condition, that is, a procedure step 
requiring intervention by a higher level before the object 
process may continue in a sensible manner. Some excep- 
tional conditions call for action by the supervisor. These 
include the following: 

(1) Fault. A fault is a clear indication of hardware 
malfunction. A memory parity error is a good example. 
The supervisor is responsible for correct operation of 
processor and memory units. 

(2) Resource excess. A resource excess occurs if a process 
invokes resources in an amount exceeding the allotment 
to the principal responsible for its computation. 

(3) Addressing snag. An addressing snag cccurs when 
a process generates a valid address, but the desired infor- 
mation is either not in main memory or a reference 
mechanism has not been set up. The supervisor must move 
the desired information into main memory from file 
storage and set up the necessary linkage. 

Other exceptional conditions should be acted upon by 
the superior computation of the process in trouble, since 
only the procedures which established the process know 
how these conditions should be interpreted. These excep- 
tional conditions are as follows. 

(1) Sphere violation. A sphere violation occurs if a 
process refers to a capability that does not exist in the C- 
list of its computation, or makes invalid use of a capability 
(attempts to write in a segment for which only the execu- 
tion capability is authorized, for example). A sphere viola- 
tion also takes place if a reference is made beyond the 
limits of a segment. 

(2) Halt imstruction. A halt means ‘terminate this 
process and notify superior” as contrasted with quit 
which means ‘“‘terminate this process and forget it.” 

(3) Breakpoint instruction. A breakpoint is substi- 
tuted for other instructions by a debugging program in 
order to conduct a breakpoint analysis of a program under 
test. A breakpoint has the same effect as halt except 
that a different indication is presented to the superior 
procedure. 

(4) Undefined instruction. A processor generates this 
condition when it is called upon to execute an undefined 
operation code. 

(5) Arithmetic contingencies. Such events as “divide 
check”? call for action by a superior procedure when not 
explicitly handled by the inferior computation. 

In any of these events, the process in which the excep- 
tional condition occurred becomes suspended, and a new 
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process is initiated in the superior sphere at the instruction 
word specified when the inferior sphere was created. The 
new process starts with two pieces of private data: a 
number indicating the reason for the interruption, and an 
index number of an owned suspended process capability 
that is appended to the C-list of the superior sphere at the 
time of interruption. This capability allows the superior 
computation to have access to the state word of the 
process in which the exceptional condition occurred. The 
following meta-instructions are defined with respect to a 
suspended process capability: 


fetch status 7, w; Fetch the state word of suspended process 
t and write at word name w. 

Set the state word of suspended process 7 
according to information at word name 
w. 

Reactivate suspended process 7 and delete 
from the C-list. 


set status 2, w; 


continue 7; 


Notice that the set status meta-instruction must disallow 
a change in certain critical parts of the state word of the 
suspended process. For example, the superior sphere must 
not be able to cause the state word of the suspended 
process to point to a different C-list. 

A debugging procedure needs primitive commands which 
allow it to “pick up the pieces” after a computation under 
test has malfunctioned. The following meta-instructions 
are useful under these circumstances: 


stop k; Suspend all processes operating in inferior 


sphere k. 


Execution of this meta-instruction causes each active 
process in inferior sphere k to be suspended. Corresponding 
to each inferior process a suspended process capability is 
created in the C-list of the superior sphere. Also, a process 
in the superior sphere is initiated to correspond to each 
inferior process, just as though the inferior process had 
encountered an exceptional condition. 

Capability 7 in the C-list of inferior sphere 7 can be 
examined by the meta-instruction 


examine 72, 7, W; 


The information contained in the capability is copied 
into several words starting at word name w. 

If the inferior computation has clogged its C-list with 
unneeded capabilities, the superior computation can 
remove them with 


ungrant 1, j; 


which erases capability 7 from the C-list of inferior sphere 7. 


Protected Entry Points 


An important class of situations arises when a peripheral 
device is operated or a data object is manipulated on be- 
half of several concurrent computations. Examples of this 
situation are: 

(1) A control routine for transferring messages between 
user computations and remote terminals of a given class, 
Frequently, a system of remote terminals is coupled to a 
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central processing system through a single i/o function 
(rather than one per terminal device). 

(2) A routine which updates a data base and may be 
called asynchronously by many separate user computa- 
tions. 

The planning of such a routine? requires that calling 
computations be protected from each other. If A and B 
are two computations using the routine S, it must not be 
possible for a malfunction of A’s processes to cause in- 
correct execution of B’s procedures. Clearly, neither A 
nor B should be able to modify the common data D used 
by S. Furthermore, A and B must be forced to initiate 
operation of S at a proper entry point, for erroneous 
transfer of control to an arbitrary instruction of S is likely 
to cause meaningless modification of the common data D. 
However, if D is to be written by S, then the processes 
executing S must have in their C-lists the capability to 
write in segment D as well as the capability to execute any 
instruction of S. 

It follows that a modification or change of C-list must 
accompany transfer of control to S. A mechanism for 
accomplishing such restricted use of a procedure we call a 
protected entry point. 

The mechanism we describe supposes that a process 
calling the protected procedure executes it in a distinct 
sphere of protection R, returning to the original sphere of 
protection A upon completion. The change of association 
of process with C-list implied here is accomplished by the 
enter meta-instruction which requires an additional 
capability, the entry. An entry capability is created by the 
owner of a protected procedure through the use of the 
meta-instruction 


h := create entry wv, 7; 


where fh is the index number in the creator’s C-list of the 
created capability. Here w is the word name [i, a], and 7 
must be the index number in the creator’s C-list of an 
owned procedure segment. The entry capability thus 
created authorizes calls to be made to the word names 
[z, a] through [z, a-+n] inclusive. Also included in the entry 
capability is a pointer to the C-list of the creating com- 
putation. Once created, the entry capability can be copied 
into the C-lists of other computations, using mechanisms 
to be described. 

The entry to and exit from a protected procedure is 
depicted schematically in Figure 5. To enter a protected 
procedure a process gives 


enter j, 7, k; 


where 7 is the index number of an entry capability. The 
calling process is suspended, and a new process is created. 
The C-list of this new process will be the C-list specified 
by the entry, with the addition of two new capabilities. 
One is a suspended process capability pointing to the state 
word of the calling process, and the other is a duplicate of 
the capability having index k in the caller’s C-list. The 
index numbers of these capabilities are reported as private 


2 Introduced as a ‘‘protected service routine” in [4]. 
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data in the state word of the new process. The new process 
is set. to begin execution at word name [?, a+7], where 7 
and a are quantities specified in the entry, as mentioned 
above. Notice that 7 is an index number with respect to 
the new C-list, not that of the caller, and also that r must 
satisfy 0 < r <n, where n is also specified in the entry. 
The remainder of the new state word is set equal to the 
corresponding parts of the caller’s suspended state word. 
Finally the new process is made active. The protected 
procedure thus given control can use the fetch status, 
set status and continue meta-instructions to communi- 
cate with the caller and reactivate his calling process 
whenever this is appropriate. 

The capability transmitted to the protected computa- 
tion (represented by index k above) can not only be a seg- 
ment capability, 1/o function capability or entry cap- 
ability, but can also be a directory capability. As described 
in the next section, a directory consists of a collection of 
capabilities. Thus the enter meta-instruction provides a 
quite general, yet reasonably efficient, facility for passing 
to the protected procedure the capabilities that it needs 
to perform its service for the caller. 


Directories and Naming 

Until now, the discussion has been covering those aspects 
of an MCS that deal with the active performance of 
computing tasks for the benefit of the system’s users. Now 
consider the fact that in most MCS8’s, even if no active 
computing is taking place, each principal of the system is 
still represented passively in the system by a set of re- 
tained objects. Every retained object is either a seg- 
ment, an i/o function, an entry or a directory. Here we 
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are letting the segment play a role which has been as- 
cribed to something called a file in many MC8’s, particu- 
larly in the MAC system. In the present formulation, a 
file is simply a long-lived segment. 


Sharing of Retained Objects. The possibility of rapidly 
and automatically controlling the sharing among prin- 
cipals of retained objects, chiefly procedure and data 
segments, is one of the main characteristics that dis- 
tinguishes the MCS from other types of computing systems 
[3]. The importance of sharing is testified to by the fact 
that the file manipulating machinery of the MAC system 
has recently undergone a major revision, motivated in 
part by a desire to facilitate such sharing [15]. 

Besides being useful to individual users who wish to 
borrow each others routines, a sharing mechanism 1s also 
useful to a group of users who wish to reference certain 
segments in common. Such segments might be a set of 
library routines or a set of procedures making up a pro- 
gramming language system. It 1s natural to think of these 
segments as being owned by a principal associated with 
the group of users as a whole. A mechanism (such as the 
one to be described) is required for permitting an indi- 
vidual user to gain access to the directory of the group 
principal. 


Desiderata for Names. Through the capabilities in 
their C-lists, computations can, among other things, 
manipulate retained objects. In performing these manip- 
ulations, the processes of a computation must specify 
information that unambiguously distinguishes each 
object of interest from all other retained objects in the 
computing system. Such information constitutes the name 
of the object. 

Retained objects are created and deleted arbitrarily, 
and any particular object may remain in existence for an 
arbitrarily long time. There are two reasons why the name 
of an object can never be changed by the system through- 
out the object’s entire existence. First, if a name is changed, 
then all usages of that name that are embedded in other 
objects (e.g., segments) within the system must be up- 
dated. This alternative may be dismissed as being entirely 
impractical in a large MCS. The second reason why the 
system must leave all names unchanged is that every 
retained object is frequently referred to directly by people. 
People are used to thinking in terms of invariant names; 
to find that yesterday’s ““X’ is suddenly today’s “Y” 
would be disconcerting. 

Another requirement which human usage places on the 
names of objects is that they should be alphanumeric and 
have mnemonic significance. Each principal should be 
able to choose freely the names by which he will identify 
the objects he retains, without regard to the choices of 
names made by other principals. 


Ambiguous Names. If the names of two different 
objects have been freely chosen by two different princi- 
pals, those names may possibly be identical. When this 
common string of characters is generated subsequently by 
a process, the computer system will not be able to deter- 
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mine which of the objects is being designated. Such a 
string of characters is said to form an ambiguous name. 

The problem of ambiguous names also manifests itself 
in more traditional, non-multiprogrammed computing 
environments when groups of independently written sub- 
programs are to be combined into one large program. One 
author has called for ‘an orderly corpus of symbology” 
designed to prevent name conflicts before they occur [16]. 
Others have offered a solution based on the loading-time 
definition of each subprogram’s symbolic interface with 
its environment [17]. 

The most straightforward way of eliminating the 
possibility of name ambiguities within an MCS is to restrict 
each principal in his choice of names; a principal can be 
required to begin every one of the names of his objects 
with a string of caracters that constitutes his principal 
name. The remainder of the name of an object, its chosen 
name, may then be freely selected by the principal re- 
taining the object. This method of preventing name con- 
flicts has been employed in the MAC time-sharing system 
{18]. 

False Names. In order to conserve storage, it is 
reasonable to embed within a procedure segment only the 
chosen names of the objects being referenced, with the 
understanding that the computer system can supply the 
principal name because it knows which principal initiated 
the process that is executing the procedure segment. Even 
if a principal has a complex program consisting of many 
procedure segments, each containing references to the 
others, the above scheme still insures that when the 
author principal operates the program the system will 
always supply the correct principal name to augment the 
chosen names embedded within the segments. 

A serious problem arises, however, if this program is 
shared with a second principal and this principal attempts 
to execute the program. Intersegment references will 
evoke the name of the second principal, rather than that of 
the author. The names thus formed will be false names, 
because they will designate objects that are very different 
from those intended by the author. Such names will often 
designate no existing object at all, but occasionally they 
may designate objects of the second principal that are 
unrelated to the borrowed program. 

Preview. The problem arises of simultaneously realiz- 
ing the following four goals: (1) to avoid the creation of 
ambiguous names, (2) to provide reasonable freedom for a 
principal to choose some portion of the names of his 
objects, (3) to allow intersegment references to consist of 
parts of names rather than full names, and (4) to permit 
sets of objects to be shared without invalidating internal 
references. 

The solution we propose stipulates that each reference 
to an object be derived from a partial name relative to 
some directory of objects, together with the index number 
of a capability pointing to that directory. Moreover, we 
allow the directories of the system to be organized into a 
hierarchical structure, as suggested by Daley and Neuman 
[19]. 
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This approach has two major advantages: 

(1) A whole subhierarchy of objects can be communi- 
cated among several computations or principals by passing 
a single pointer to the head directory of the subhierarchy. 

(2) It is easy to design the MCS so that programs can be 
shared without the possibility that false names will be 
generated by their execution. 

In the following paragraphs we define the proposed 
naming structure and introduce the meta-instructions 
necessary for computing within its framework. 

Directories. A directory is a set of items, each being an 
association between a name component and a capability 
which points to a segment, i/o function, entry or another 
directory. Recall that each capability includes an owner- 
ship indicator (O for owned, N for not owned), and that a 
segment capability includes an indication (R, W, X or a 
combination) of the type of reference permitted. Each 
item of a directory also contains an access indicator (P 
for private, F, for free). The interpretation of these 
indicators in directories is explained below. 

Associated with each principal is exactly one directory 
called a root directory, which stands at the head of a 
hierarchy of the principal’s retained objects. We allow 
perhaps many items to point to the same object, and in 
consequence, an object may be accessible through the 
directory structure from different root directories. 

Ownership. <A principal always owns his root directory. 
Otherwise, an object is owned by a principal just if that 
principal owns a directory in which there exists an item 
with an O indicator that points to the object. Thus, a 
principal owns an object if and only if there is a path 
through the directory tree from his own root directory to 
the object such that each node of the path contains an O 
indicator. 

When the supervisor creates a computation on behalf of 
a principal, it always places in the C-list of such a com- 
putation a directory capability with an O indicator that 
points to the principal’s root directory. The principal is 
then said to own this computation and each of its processes. 
These processes are then permitted to exercise powers of 
ownership with respect to objects owned by the principal. 

Using the Directory Structure. The powers of a computa- 
tion with respect to the directory structure are embodied 
in meta-instructions as follows. We suppose that any 
process has at least one entry in its C-list giving it a 
directory capability. 

n | 
x 


j= acquire z, (name component); 


R 
XR 
RW 
XRW 





Here 7 is the index number of a directory capability. This 
directory is searched for an association with (name 
component), the corresponding capability is entered into 
the C-list of the computation to which the running process 
belongs, and its index number is reported as 7. Capability 
7 is tagged O if and only if directory 7 is tagged O in the 
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C-list, and the capability being loaded is tagged O in 
directory 7. A sphere violation results if the capability 
referenced is tagged P in the directory item and directory 
capability 7 is not owned (i.e., contains an N indicator). 
In the case of a segment, the type of reference permitted 
may be changed from that permitted in the directory item, 
but an attempt to enlarge the class of reference permitted 
to a nonowned segment is also deemed a sphere violation. 


release 7; 


Remove the capability with index number 7 from the C- 
list of the running process. 

Ownership of an object implies the ability to modify it, 
delete it, and grant access to the object by other principals. 


Pl. ‘ 
place FF {name component), j; 


Here 7 must be the index number of an owned directory 
capability. An item is inserted in directory 7 associating 
the capability having index number j with (name com- 
ponent). 


remove 7, (name component) 


The item associated with (name component) in owned 
directory 7 is removed from the directory. 

Creation and Deletion of Retained Objects. Segments, 
entires and directories can come into existence upon 
execution of the following meta-instructions. 

a 
R 
segment XR}; 
RW 
1 := create XRW 
entry Ww, 7 
directory; 
A capability pointing to the created object is entered into 
the C-list of the process with an O indicator, and its index 
number is reported as 7. Note that a name is not associated 
with the object at the time of its creation, but only when 
an entry is made for it in some directory by means of a 
place meta-instruction. 

This illustrates the point that names are a convenience 
for principals. Different names may be convenient for 
different principals, and no name need be assigned unless a 
principal may need to select that object from the directory 
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structure at a later time. Thus for example, segments may 
be created by computations for temporary storage pur- 
poses without affecting the directory structure. 

The owner of a segment, entry or directory can cause it 
to cease to exist by using the following meta-instruction: 


delete 7, (name component); 


The owned object pointed to by the capability associated 
with (name component) in directory 7 is deleted so that it 
has no further existence. Any attempts to exercise cap- 
abilities pointing to a deleted object are treated as sphere 
violations. 

The release and remove meta-instructions differ from 
delete in that the former meta-instructions simply remove 
capabilities from C-lists and items from directories, 
respectively, while the object itself continues its existence 
if there are other capabilities and items pointing to it. 

We suppose then that the existence of a segment, entry 
or directory extends from its time of creation until either 
specifically delete’ed by its owner or until release’ed 
from all C-lists and remove’ed from all directories. This 
convention yields the possibility of having a retained 
object. with no owner. This seems quite reasonable be- 
cause the following situation may occur frequently. An 
obsolete subroutine segment S is remove’ed from the 
directories of a library principal L but remains in use by 
principals A, B and C. The segment was previously owned 
by L, but now has no owner. The existence of S continues 
just until A, B and C have abandoned use of it. Since we 
assume there can be no more than one owner of an object, 
the only alternatives are to assign ownership to one of A, 
B or C (but how do we choose?), or to generate separate 
copies of S for each sharing principal. 

The Structure of Names. Since every computation 
initially has in its C-list at least one root apex directory 
capability, it is clear that by giving a series of acquire’s, a 
computation can make its way through the directory 
structure along any path, as long as it knows the correct 
series of name components to use. A series of name com- 
ponents leading from a directory to an object is called the 
partial name of the object with respect to that directory. 

Because of the structure of the directories, an object 
can have many names, as well as many partial names with 
respect to any directory. For example, the directory 
structure in Figure 6 shows a particular segment, owned 
by the principal FORTRAN, which has the following 
names: 

FORTRAN, MATRIX, MULTIPLY 

DENNIS, EXPERIMENT, SUBROUTINES, MATMULT 

DENNIS, CIRCUITTHEORY, MAXPROD 

VANHORN, DENNISEXP, SUBROUTINES, MATMULT 


Notice that the item named DENNISEXP within the 
root directory VANHORN points to the directory whose 
full name is DENNIS, EXPERIMENT 

Sharing Mechanisms. Two mechanisms to allow the 
sharing of retained objects are described here. One mecha- 
nism gives blanket authority to all computations within the 
system to acquire the shared object. The other mechanism 
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allows the owner of an object to specifically authorize each 
instance of its sharing. 
The meta-instruction 


4 := link (principal name); 


inserts into the C-list at index 7 a nonowned directory 
capability pointing to the root directory named (principal 
name). Using the acquire meta-instruction, a computa- 
tion can thus gain access to any object in the directory 
structure of any principal, provided that the directory 
items leading from the principal directory to the object all 
contain F indicators. 

Any more selective sharing mechanism requires an 
explicit interaction between the borrower and the lender. 
We propose that the shared capability be passed between 
the C-lists of two computations that interact via the enter 
meta-instruction. 

A typical interaction might proceed as follows. The 
lender first creates a free entry capability in one of its 
directories. The borrower then uses link and acquire to 
place this entry capability in its C-list. The borrower next 
creates a special entity in its C-list, called a receiver, by 
means of the meta-instruction 


4 := receive; 


Finally the borrower exercises the entry obtained from the 
lender by using enter. Parameters passed as private data 
provide to the lender the index 7 of the receiver in the 
borrower’s C-list, as well as information identifying the 
capability desired to be borrowed. 

The lender is thus given control, and proceeds to verify 
the right of the borrower to obtain the capability re- 
quested. In particular, the lender may wish to verify that 
the borrower computation is in fact owned by a certain 
principal. For this purpose the lender uses the meta- 
instruction 


$ := owner J; 


where j is the index in the lender’s C-list of the suspended 
process capability generated by the enter operation, and 
s is a string giving the principal name of the owner of the 
suspended process. 

Having completed its verification, the lender then 
acquire’s into its own C-list the owned capability it 
wishes to transmit. If this capability has index k, the meta- 
instruction 


transmit j, 2, k; 


replaces receiver 7 in the C-list of suspended process j 
with the owned capability k, giving it an N tag. 

Having modified the borrower’s C-list, the lender then 
returns control to the borrower with continue. At this 
point the loan is complete; the borrower may now exercise 
the capability and place it in one of his own directories. 

An Example: Using a Programming System. Suppose a 
user wishes to use a programming system PS. The retained 
objects (procedure segments, directories, entries, etc.), 
of PS are on file in the hierarchical organization already 
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outlined (Iigure 7b). The user has his objects organized 
in a private hierarchy (Iigure 7a). If the use of PS is only 
desired for one user, then it is appropriate for an owned 
item in the user’s directory structure to point to the 
directory structure of PS. If it is desired to make PS 
available to many or all principals at an installation, it is 
appropriate to place the directory hierarchy of PS under a 
principal of its own or as a subhierarchy within the domain 
of a common programming system principal. In either case, 
a computation for a user involving retained objects both 
of his own and of the PS would be carried out in the follow- 
ing manner: 

(1) The user initiates a process which acquires access 
capabilities for the two hierarchies of directories—one for 
his own files and one for PS—by executing the necessary 
sequence of meta-instructions. Suppose these capabilities 
have index numbers 7 and 7 respectively. 

(2) PS is called with 7 and 7 as parameters. PS does all 
addressing within the directory structure relative to the 
roots of their trees represented by entries 7 and 7 of the C- 
list (Figure 7). 
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The Structure of Programming Languages 


Bertram Raphael 
Stanford Research Institute, Menlo Park, California 


(Abstract Only and Discussion) 


The following are identified as major components of every 
programming language: (1) the elementary program state- 
ment, (2) mechanisms for linking elementary statements to- 
gether, (3) the means by which a program can obtain data 
inputs. Several alternative forms of each of these components 
are described, compared and evaluated. Many examples, 
frequently from list processing languages, illustrate the forms 
described. 

Elementary program statements usually take the form of 
commands, requirements, or implicit specifications. A command 
is an imperative statement that commands the action to be 
taken. A requirement describes the effect to be achieved 
without saying anything about the actions to be taken. An 
implicit specification is similar to a requirement, but the pro- 
grammer must understand what actions will be taken to achieve 
the desired effect. 
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Subroutines may be entered explicitly, by execute call, or 
by function composition. Explicitly called subroutines generally 
require special linkage conventions. An execute subroutine call 
is syntactically indistinguishable from a basic instruction of the 
programming language. Function composition is a convenient 
alternative to the explicit call. 

The three principal ways of getting inputs for routines are 
(1) by referring to the data itself, (2) by referring to the data 
by a “name”, and (3) by referring to it implicitly by means of 
variables or functions. Names are useful entry points into 
permanent data structures, but can be error-causing distrac- 
tions in other contexts. 

The author disadvantages, and 
factors influencing the choice of a form of component for a 
language. He concludes by suggesting the evolution of pro- 


discusses advantages, 


gramming languages toward one which will permit all the 
most convenient ways of structuring programs, organizing sys- 
tems, and referencing data. 
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